I pushed changes to use another semaphore library that is already used by Theia: async-mutex.

I also cleaned up the class to get rid of the asynchronous postConstruct as this is a mistake when using Inversify 4.

Lastly, is there a way to write browser tests for this fix? From what I understand this class is quite nested in the plugin system infrastructure, so if it's too difficult writing integration tests please write unit tests then.

Here's an example for a unit test I think could be good:

const tasks = [];
for (let i = 0; i < 1000; i++) {
    tasks.push(storage.set('test_value', i));
}
await Promise.allSettled(tasks);
assert.deepStrictEqual(
    await storage.get('test_value'),
    999,
    'the last value being set should have been 999'
);

edit: Updated the snippet to something that should work

Previously the result of this snippet would have been non deterministic?

The last commit I pushed adds logic to use unique mutexes based on the file path being written to. It seems to be something that can happen based on the kind parameter passed to several methods. This is better than locking access to unrelated files by using the same global lock.

One thing to consider, at least re: writing: there's already something doing a somewhat similar job for our preference files on the frontend in packages/preferences/src/browser/preference-transaction-manager.ts. The only thing missing for it to work on the backend is a backend equivalent to the MonacoJSONCEditor in packages/preferences/src/browser/monaco-jsonc-editor.ts

@colin-grant-work is it me or the component you linked seems hyper-specific to preferences?

The FileSystemLocking service introduced here is mostly a generic mutex bag and doesn't make any assumption about what you might do while having exclusive access (use the node APIs or don't)

@colin-grant-work is it me or the component you linked seems hyper-specific to preferences?

Yes, but it would do the job that we need to do for the globalState mechanism, since that also just manages a JSON file.

it seems to me we only need to read from the file once at startup, and after that, all changes can be kept in memory and written to the underlying storage only at the end of the session (or periodically to avoid breakdown).

I've thought about it too, but it would require heavily modifying this component. The way it currently operates might not be the most efficient you are right, and the current fix was the lowest effort required to patch the issue.

I'll look into storing key/values in memory and periodically synchronizing on disk.

I also think that @tsmaeder's point about this being an OS-level problem merits serious consideration, because two Theia instances running on the same machine will both want access to the same files, and as long as we're not using the single-instance lock to ensure that we only have one backend, we've got no guarantee that they won't be operating on the file at the same item. It also increases the urgency of keeping the file up to date with regular writes, because the second instance would want to have an up-to-date version of the data when it starts up. But that means that all changes need to be written promptly to disk, and that means that the probability of OS-level concurrent access is non-negligible.

Looking at "system file locking" was inconclusive, and only the proper-lockfile package looks usable which would prevent two Theia instances from conflicting. Other processes can still mess up with our files, but at this point it's out of scope.

It then depends on what kind of behaviour we want: The current approach assumes any update is directly written on disk and visible by subsequent accesses. I'm not sure of the benefits from this approach.

Well, proper-lockfile doesn't seem to work when the file doesn't yet exist.

@colin-grant-work I used the strategy you mentioned where we use an in-memory cache first for the values, and only sync with the disk every so often. The sync delay is long enough with a bit of randomness as to avoid collisions with other Theia instances. It might not be fool-proof but it's arguably better than the previous implementation. I think we'll have a long and happy life before we'll get to see problems with this new implementation, but I might be wrong.

Well, proper-lockfile doesn't seem to work when the file doesn't yet exist.

Have you tried to disable the realPath option? Else creating an empty file first, if/when it doesn't yet exists, looks like a viable option (the file itself is not used as the lock, so this should not introduce race conditions).

The scope of the PR has changed quite a bit, so probably the title/description should be updated accordingly.

To @msujew, @JonasHelming, can someone from either TypeFox or EclipseSource review this patch?

Summary of the changes so far: Don't access the disk for each read/write access and instead synchronize on disk every so often. Prevention against multiple Theia instances trying to use the same file is postponed until someone else is free to implement it as it should be easy to add later if we need it (just update the lockPath implementation).